fix: add SHA-256 checksum verification to GitHub release downloads#288
Open
xiaolai wants to merge 1 commit into
Open
fix: add SHA-256 checksum verification to GitHub release downloads#288xiaolai wants to merge 1 commit into
xiaolai wants to merge 1 commit into
Conversation
downloadRelease() previously wrote the downloaded ZIP to disk without any integrity check. A compromised release asset would be silently installed into user projects. Changes: - Add getChecksumUrl() helper that looks for a companion `.sha256` or `checksums.txt` asset in the release - Add optional checksumUrl parameter to downloadRelease(); if a checksum URL is provided and the fetch succeeds, compute SHA-256 of the downloaded buffer and compare before writing to disk - Add GitHubChecksumError class for mismatch failures - Update init.ts to look up and pass the checksum URL when present This is forward-compatible: if no checksum asset is uploaded the behavior is unchanged. Maintainers can enable full verification by uploading a `<asset-name>.sha256` companion file to each release. Co-Authored-By: Claude Code <noreply@anthropic.com>
This was referenced Apr 26, 2026
mrgoonie
requested changes
Jun 21, 2026
mrgoonie
left a comment
mrgoonie
left a comment
Contributor
There was a problem hiding this comment.
Summary: Optional release checksum verification is a good security direction, but this PR duplicates an adjacent open checksum PR and the implementation has an unsafe fallback that silently ignores checksum fetch failures.
Risk level: Medium
Mandatory gates:
- Duplicate/prior implementation: overlap found — PR #285 implements the same SHA-256 release download verification path against the same files, and PR #315 also includes broader release/download hardening.
- Project standards: issue found — the CLI currently treats GitHub download failures as install blockers or explicit fallback paths; checksum verification should not look enabled while silently skipping a failed checksum fetch.
- Strategic necessity: clear value — verified release assets would reduce supply-chain risk for the legacy GitHub install path.
- CI/checks: missing/not reported for this PR.
Findings:
- Important: This materially duplicates PR #285. Both PRs modify `cli/src/commands/init.ts` and `cli/src/utils/github.ts` to add optional SHA-256 verification for release downloads. Please consolidate around one checksum design instead of merging competing implementations.
- Important: When a checksum asset exists but fetching it fails, `downloadRelease()` currently proceeds without verification because it only checks `if (checksumResponse.ok)` and otherwise falls through to `writeFile()`. That creates a dangerous false sense of integrity protection: a transient or blocked checksum fetch silently downgrades security. If a checksum URL was selected, failure to fetch or parse it should fail closed with a clear checksum/download error.
Verdict: REQUEST_CHANGES
mrgoonie
added
agent:github-maintain
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Security Fix (Medium)
cli/src/utils/github.ts—downloadRelease()fetches a ZIP from GitHub releases and writes it directly to disk without any integrity check.init.tsthen extracts and installs the contents into the user's project. A compromised release asset (e.g. from a hijacked GitHub token or a compromised release pipeline) would be silently installed with no way for the user to detect the tamper.Fix: This PR adds opt-in SHA-256 verification using a companion checksum asset pattern:
getChecksumUrl(release, assetName)— looks for a<asset-name>.sha256orchecksums.txtasset in the GitHub releasedownloadRelease(url, dest, checksumUrl?)— ifchecksumUrlis provided and the fetch succeeds, computesSHA-256of the downloaded buffer and compares against the expected hash before writing to disk; throwsGitHubChecksumErroron mismatchinit.tsnow callsgetChecksumUrl(release, assetName)and passes the result todownloadReleaseThis is backward-compatible: if no companion checksum asset is uploaded, the behavior is identical to the current code. To enable full verification, upload a
release.zip.sha256(orchecksums.txt) companion file to each GitHub release — the CLI will then automatically verify before installation.